A Uniform Resource Locator (URL) is used to define the route to a specified resource in Internet server. In current art, any resource that can be accessed on the Internet is assigned a unique URL, and client software such as an HTML browser can access a corresponding resource using the URL. However, current URLs cannot satisfy the requirement of users very well in terms of reproduction of dynamic network resource and granularity access. In particular, more and more network resources are generated in a dynamic manner by a server. This results in the content being displayed differently when accessed by different users through the same URL, or when accessed by the same user through the same URL in different scenarios (such as different time). That is, the resource generated dynamically cannot be reproduced, thus inconveniencing the users.
For example, FIG. 1 shows an HTML page of stock price statistic, in which a graph is used to represent the price variations of stock exchange. It is easy to see that the graph must be varied as time varies. For instance, the graph viewed by user A through finance.ibm.com/stock/company/sh60008/nc.shtml in the first day is different from the graph viewed through the same URL in the second day. That is, user A cannot view the graph of the first day through the above URL on the second day and afterwards. Therefore, if user A wishes to be able to refer to the stock trend for previous instances of tie, the user can only save the daily graphs and related pages manually. This not only occupies large amounts of storage space in the client, but also is quite troublesome. Moreover, since user A saves the graphs and related pages in his local machine, other users in the network cannot obtain these resources by accessing the network server. If user A wishes to share these resources with other users in the network, the user has to distribute the saved graph resource to each of the other users, which is obviously troublesome and time-consuming.
In another aspect, when a URL is used it is often regarded as a file, that is, the user cannot specify the URL for any lower granularity of a resource, e.g., a function in the web application or a fragment of HTML document. With the appearance and development of Web 2.0, the need for simply integrating parts of the functions of different web applications together is more and more proposed. A typical scenario is that, when a user sees a calendar widget in a website, the user would like to mash it up into his/her personal blog site, instead of developing this calendar widget himself/herself. Under this trend, people have begun to consider using REST architecture to specify a URL for a specified resource (e.g., specifying URL for respective functions of the web applications) by providing RESTful API, and integrating the fragments of different resources together using mash-up technique. However, for most current conventional applications, RESTful API is not provided to realize mash-up, thus a lot of coding work still has to be done when performing functional integration among different web applications.